-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Migrate inventory code #861
Conversation
Copy all files currently living in https://github.com/Malax/inventory/tree/main/inventory/src without any changes. Co-Authored-By: Manuel Fuchs <[email protected]> Co-Authored-By: Josh W Lewis <[email protected]>
0c039db
to
1e47371
Compare
1e47371
to
8c99bc5
Compare
We may want to consider another approach here (e.g. naming the feature `inventory-sha2` and/or pulling in the inventory dependency ["inventory", "dep:sha2"]). While the crate will be pulled in if a user enables the `sha2`, the inventory-specific sha2 code won't be compiled unless the `inventory` feature is also enabled.
8c99bc5
to
99d7d3a
Compare
These re-exports appear to be unnecessary, and doesn't have any impact on code that rely on the `inventory` module (and have the `semver` and/or `sha2` features enabled). Also see related prior discussion here Malax/inventory#2 (comment). The `semver` and `sha2` modules only contain implementations of public traits, so I don't think we need to re-export those (unlike bringing for instance a function or struct in to scope). If I understand how trait implementations work correctly, it doesn't matter where an implementation lives (only the visibility of the trait and the type it's implemented for is relevant) - in other words, the implementation will be available to any code that can access both the trait and the type, even across crate binaries.
e41dc7a
to
369a70f
Compare
There's a few comments on docs. I took a stab at it in a stacked PR #864. Feedback/review is welcome over there or it's free to be merged in here and iterated on. The only known pending thing is i put the feature names in the docs as TODO. |
* Add module docs and example * Document resolve and partial_resolve * Document more inventory methods * Document Artifact * Document ArtifactRequirement I also suggest we change the name of `inventory/version` to `inventory/artifact_requirement.rs` or `requirement.rs`. * Update example to compare Checksum instead of string * Apply suggestions from code review Co-authored-by: Rune Soerensen <[email protected]> * Update feature names * Rewrite example usage * Show how to display checksum in example --------- Co-authored-by: Rune Soerensen <[email protected]>
@joshwlewis I've merged Richard's documentation PR - I think should address your documentation comments? |
@Malax I think this is waiting on you now. It looks like the changes you requested have been made. Can we get a 👍🏻? |
This PR imports and migrates the inventory code here to the
libherokubuildpack
crate. The code was copied as-is and added in the first commit, and I've tried to keep changes to integrate it to a minimum.I'm not sure what the best approach is to adapt the
sha2
andsemver
feature flags from the source inventory crate - perhaps it's fine as-is, or perhaps it'd make sense to use different feature names given the new context/crate for the code. Relevant commit with comment.I've removed a couple re-exports that appear to be unnecessary - see explanation in this commit.